Real-time conversations between conversation participants via their computer systems are becoming increasingly common. Such real-time conversations require that the participants be present at their computer systems (e.g., personal digital assistants) and able to respond when a communication is received. A common form of real-time conversation is provided by instant messaging services. An instant messaging service allows participants to send messages and have them received within a second or two by the other participants in the conversation. The receiving participants can then send responsive messages to the other participants in a similar manner. To be effective, a real-time conversation relies on the participants' becoming aware of, reviewing, and responding to received messages very quickly. This quick response is in contrast to conventional electronic mail systems in which the recipients of electronic mail messages respond to messages at their convenience.
To support real-time communications, communications applications typically need to establish and manage connections (also referred to as sessions or dialogs) between computing devices. A session is a set of interactions between computing devices that occurs over a period of time. As an example, real-time communications applications such as MESSENGER or VoIP establish sessions between communicating devices on behalf of users. These applications may use various mechanisms to establish sessions, such as the Session Initiation Protocol (“SIP”). SIP is an application-level control protocol that computing devices can use to discover one another and to establish, modify, and terminate sessions between computing devices. SIP is a proposed Internet standard. The SIP specification, “RFC 3261,” is available at <http://www.ietf.org/rfc/rfc3261.txt>.
A SIP network comprises entities that can participate in a dialog as a client, server, or both. SIP supports four types of entities: user agent, proxy server, redirect server, and registrar. User agents initiate and terminate sessions by exchanging messages with other SIP entities. A user agent can be a user agent client (“UAC”), which is a device that initiates SIP requests, or a user agent server (“UAS”), which is a device that receives SIP requests and responds to such requests. As examples, “IP-telephones,” personal digital assistants, and any other type of computing device may be user agents. A device can be a UAC in one dialog and a UAS in another, or may change roles during the dialog. A proxy server is an entity that acts as a server to clients and a client to servers. In so doing, proxy servers intercept, interpret, or forward messages between UACs and UASs. A redirect server accepts a SIP request and generates a response directing the UAC that sent the request to contact an alternate network resource. A registrar is a server that accepts registration information from user agents and informs a location service of the received registration information.
SIP supports two message types: requests, which are sent from a UAC to a UAS, and responses, which are sent from a UAS to a UAC when responding to a request. A SIP message is composed of three parts. The first part of a SIP message is a “request line,” which includes fields to indicate a message method (e.g., INVITE) and a request URI that identifies the user or service to which the request is being directed. The second part of a SIP message comprises headers whose values are represented as name-value pairs. The third part of a SIP message is the message's body, which is used to describe the session to be initiated or contain data that relates to the session. Message bodies may appear in requests or responses.
For example, in an instant messaging context, a publishing user (“publisher”) may provide their presence information to a presence server that then provides the presence information to subscribing users (“subscribers”). Thus, a presence server may use a subscriber/publisher model to provide the presence information for the users of the presence service. Whenever the presence information of a user changes, the presence server is notified of the change by that user's computer system and in turn notifies the subscribing users of the change. A subscribing user can then decide whether to initiate an instant messaging conversation based on the presence information of the intended participants. For example, if the presence information indicates that a publishing user is currently in a conference telephone call, then the subscribing user may decide to send an instant message, rather than place a telephone call, to the publishing user. If the subscribing user, however, needs to call and speak with the publishing user, the subscribing user needs to monitor the presence information of the publishing user to know when the call can be placed. When the subscribing user notices that the publishing user's presence information indicates that the telephone conference has been concluded, the subscribing user can then place the telephone call. A specification relating to presence information in instant messaging systems, “RFC 2778,” is available at <http://www.ietf.org/rfc/rfc2778.txt>. A draft of a proposed specification relating to presence information using the Session Initiation Protocol (“SIP”) is available at <http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-10.txt>.
In a typical scenario, an endpoint registers with the presence server. The endpoint then sends SUBSCRIBE requests to the presence server for each of the contacts on the user's contact list specifying a non-zero subscription expiration and an event type of “presence.” The presence server sends a response to each request indicating success or failure of the subscription. After a successful subscription, the presence server sends to the endpoint a NOTIFY request containing the current presence document of the subscribed-to contact. The endpoint sends a response to each NOTIFY request indicating success or failure of the notification. Therefore, an endpoint and server exchange four messages for each contact to which a user subscribes: a SUBSCRIBE request, SUBSCRIBE response, NOTIFY request, and NOTIFY response.
It is not uncommon for a user to register more than one endpoint with a presence server. For example, a user can register a personal digital assistant, a wireless telephone, a laptop computer, and a desktop computer as endpoints. Subsequently, an initiator of a conversation (e.g., a calling participant) may invite the user to participant in the conversation. Here, the calling participant's endpoint sends a SIP INVITE message to invite the user into the conversation. The SIP INVITE message is forwarded or forked by an intermediate server, such as a “forking” server, to all of the user's registered endpoints. The intermediate server typically waits to receive responses from one or more of the endpoints and sends one of the received responses to the calling participant's endpoint. The intermediate server arbitrarily chooses a response, typically the first response received from one of the user's endpoints, to send back to the calling participant's endpoint. More often than not, by arbitrarily choosing a response, the intermediate server fails to select the most appropriate or desirable response to send to the calling participant's endpoint.